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Abstract 


This document is an integral part of the Lightweight Directory Access 
Protocol (LDAP) technical specification. It provides a technical 
specification of attribute types and object classes intended for use 
by LDAP directory clients for many directory services, such as White 
Pages. These objects are widely used as a basis for the schema in 
many LDAP directories. This document does not cover attributes used 
for the administration of directory servers, nor does it include 
directory objects defined for specific uses in other documents. 
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Introduction 
This document provides an overview of attribute types and object 
classes intended for use by Lightweight Directory Access Protocol 
(LDAP) directory clients for many directory services, such as White 
Pages. Originally specified in the X.500 [X.500] documents, these 
objects are widely used as a basis for the schema in many LDAP 
directories. This document does not cover attributes used for the 
administration of directory servers, nor does it include directory 
objects defined for specific uses in other documents. 
1. Relationship with Other Specifications 


This document is an integral part of the LDAP technical specification 
[RFC4510], which obsoletes the previously defined LDAP technical 
specification, RFC 3377, in its entirety. In terms of RFC 2256, 
Sections 6 and 8 of RFC 2256 are obsoleted by [RFC4517]. Sections 
5.1, 5.2, 7.1, and 7.2 of RFC 2256 are obsoleted by [RFC4512]. The 
remainder of RFC 2256 is obsoleted by this document. The technical 
specification for the 'dc” attribute type and 'dcObject” object class 
found in RFC 2247 are superseded by sections 2.4 and 3.3 of this 
document. The remainder of RFC 2247 remains in force. 
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This document updates RFC 2798 by replacing the informative 
description of the ’uid’ attribute type with the definitive 
description provided in Section 2.39 of this document. 


This document updates RFC 2377 by replacing the informative 
description of the ‘’uidObject’ object class with the definitive 
description provided in Section 3.14 of this document. 


A number of schema elements that were included in the previous 
revision of the LDAP Technical Specification are not included in this 
revision of LDAP. PKI-related schema elements are now specified in 
[RFC4523]. Unless reintroduced in future technical specifications, 
the remainder are to be considered Historic. 


The descriptions in this document SHALL be considered definitive for 
use in LDAP. 


1.2. Conventions 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


1.3. General Issues 


This document references Syntaxes defined in Section 3 of [RFC4517] 
and Matching Rules defined in Section 4 of [RFC4517]. 


The definitions of Attribute Types and Object Classes are written 
using the Augmented Backus-Naur Form (ABNF) [RFC4234] of 
AttributeTypeDescription and ObjectClassDescription given in 
[RFC4512]. Lines have been folded for readability. When such values 
are transferred as attribute values in the LDAP Protocol, the values 
will not contain line breaks. 


2. Attribute Types 
The attribute types contained in this section hold user information. 
There is no requirement that servers implement the ’searchGuide’ and 
"teletexTerminalldentifier” attribute types. In fact, their use is 


greatly discouraged. 


An LDAP server implementation SHOULD recognize the rest of the 
attribute types described in this section. 
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2.1. 'businessCategory”' 


The 'businessCategory” attribute type describes the kinds of business 
performed by an organization. Each kind is one value of this 
multi-valued attribute. 

(Source: X.520 [X.520]) 


( 2.5.4.15 NAME ’businessCategory’ 
EQUALITY caselgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 


1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax 
[RFC4517]. 


Examples: "banking", "transportation", and "real estate". 
2e25 UG! 
The ’c’ (’countryName’ in X.500) attribute type contains a two-letter 
ISO 3166 [ISO3166] country code. 
(Source: X.520 [X.520]) 
( 2.5.4.6 NAME 'c” 

SUP name 

SYNTAX 1.3.6.1.4.1.1466.115.121.1.11 

SINGLE-VALUE ) 


1.3.6.1.4.1.1466.115.121.1.11 refers to the Country String syntax 
[RFC4517]. 


Examples: "DE", "AU" and "FR". 
Zady Ten” 


The 'cn” (’commonName’ in X.500) attribute type contains names of an 


object. Each name is one value of this multi-valued attribute. If 
the object corresponds to a person, it is typically the person's full 
name. 


(Source: X.520 [X.520]) 


( 2.5.4.3 NAME “cn” 
SUP name ) 


Examples: "Martin K Smith", "Marty Smith" and "printerl2". 
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24-5 “ac” 


The ’dc’ (’domainComponent’ in RFC 1274) attribute type is a string 
holding one component, a label, of a DNS domain name 

[RFC1034] [RFC2181] naming a host [RFC1123]. That is, a value of this 
attribute is a string of ASCII characters adhering to the following 
ABNF [RFC4234]: 


label = (ALPHA / DIGIT) [*61(ALPHA / DIGIT / HYPHEN) (ALPHA / DIGIT) ] 
ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" 

DIGIT = %x30-39 ; "o"-"9" 

HYPHEN = %x2D ; hyphen ("-") 


The encoding of IA5String for use in LDAP is simply the characters of 
the ASCII label. The equality matching rule is case insensitive, as 
is today’s DNS. (Source: RFC 2247 [RFC2247] and RFC 1274 [RFC 1274]) 


( 0.9.2342.19200300.100.1.25 NAME dc” 
EQUALITY caseIgnoreIA5Match 
SUBSTR caselgnorelA5SubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
SINGLE-VALUE ) 


1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String syntax 
[RFC4517]. 


Examples: Valid values include "example" and "com" but not 
"example.com". The latter is invalid as it contains multiple domain 
components. 


It is noted that the directory service will not ensure that values of 
this attribute conform to the host label restrictions [RFC1123] 
illustrated by the <label> production provided above. It is the 
directory client’s responsibility to ensure that the labels it stores 
in this attribute are appropriately restricted. 


Directory applications supporting International Domain Names SHALL 
use the ToASCII method [RFC3490] to produce the domain component 
label. The special considerations discussed in Section 4 of RFC 3490 
[RFC3490] should be taken, depending on whether the domain component 
is used for "stored" or "query" purposes. 


2.5. ‘description’ 
The 'description” attribute type contains human-readable descriptive 
phrases about the object. Each description is one value of this 


multi-valued attribute. 
(Source: X.520 [X.520]) 
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( 2.5.4.13 NAME ’description’ 
EQUALITY caseIgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX 1.3.6.1; 4 01. 1466Ul50312L% 1.15) 


1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax 


[RFC4517]. 
Examples: "a color printer", "Maintenance is done every Monday, at 
lpm.", and "distribution list for all technical staff". 
2.6. ‘’destinationIndicator’ 


The ’destinationIndicator’ attribute type contains country and city 
strings associated with the object (the addressee) needed to provide 
the Public Telegram Service. The strings are composed in accordance 
with CCITT Recommendations F.1 [F.1] and F.31 [F.31]. Each string is 
one value of this multi-valued attribute. 

(Source: X.520 [X.520]) 


( 2.5.4.27 NAME ’destinationIndicator’ 
EQUALITY caseIgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 ) 


1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax 
[RFC4517]. 


Examples: "AASD" as a destination indicator for Sydney, Australia. 
"GBLD" as a destination indicator for London, United 
Kingdom. 


It is noted that the directory will not ensure that values of this 
attribute conform to the F.1 and F.31 CCITT Recommendations. It is 
the application’s responsibility to ensure destination indicators 
that it stores in this attribute are appropriately constructed. 


2.7. ‘distinguishedName’ 


The ’distinguishedName’ attribute type is not used as the name of the 
object itself, but it is instead a base type from which some user 
attribute types with a DN syntax can inherit. 


It is unlikely that values of this type itself will occur in an 
entry. LDAP server implementations that do not support attribute 
subtyping need not recognize this attribute in requests. Client 
implementations MUST NOT assume that LDAP servers are capable of 
performing attribute subtyping. 
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(Source: X.520 [X.520]) 


( 2.5.4.49 NAME /distinguishedName’ 
EQUALITY distinguishedNameMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 


1.3.6.1.4.1.1466.115.121.1.12 refers to the DN syntax [RFC4517]. 
2.8. ‘’dnQualifier’ 


The ’dnQualifier’ attribute type contains disambiguating information 
strings to add to the relative distinguished name of an entry. The 
information is intended for use when merging data from multiple 
sources in order to prevent conflicts between entries that would 
otherwise have the same name. Each string is one value of this 


multi-valued attribute. It is recommended that a value of the 
‘dnQualifier’ attribute be the same for all entries from a particular 
source. 


(Source: X.520 [X.520]) 


( 2.5.4.46 NAME '*dnQualifier” 
EQUALITY caseIgnoreMatch 
ORDERING caseIgnoreOrderingMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX: 1.3..61.4.1..1466..115.121.. 1.44 :) 


1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax 


[RFC4517]. 
Examples: "20050322123345Z" - timestamps can be used to disambiguate 
information. 
"123456A" - serial numbers can be used to disambiguate 
information. 
2.9. ‘enhancedSearchGuide’ 


The ’enhancedSearchGuide’ attribute type contains sets of information 
for use by directory clients in constructing search filters. Each 
set is one value of this multi-valued attribute. 

(Source: X.520 [X.520]) 


( 2.5.4.47 NAME ’ enhancedSearchGuide’ 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 ) 


1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide syntax 
[RFC4517]. 
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Examples: "person#(snSAPPROX) twholeSubtree" and 
"organizationalUnit# (ou$SUBSTR) #oneLevel". 


2.10. ’facsimileTelephoneNumber’ 


The 'facsimileTelephoneNumber” attribute type contains telephone 
numbers (and, optionally, the parameters) for facsimile terminals. 
Each telephone number is one value of this multi-valued attribute. 
(Source: X.520 [X.520]) 


( 2.5.4.23 NAME 'facsimileTelephoneNumber” 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 ) 


1.3.6.1.4.1.1466.115.121.1.22 refers to the Facsimile Telephone 
Number syntax [RFC4517]. 


Examples: "+61 3 9896 7801" and "+81 3 347 7418$fineResolution". 
2.11. ‘’generationQualifier’ 

The ’generationQualifier’ attribute type contains name strings that 

are typically the suffix part of a person’s name. Each string is one 

value of this multi-valued attribute. 


(Source: X.520 [X.520]) 


( 2.5.4.44 NAME '“generationQualifier' 
SUP name ) 


Examples: "III", "3rd", and "Jr.". 

2.12. 'givenName” 
The 'givenName” attribute type contains name strings that are the 
part of a person's name that is not their surname. Each string is 
one value of this multi-valued attribute. 


(Source: X.520 [X.520]) 


( 2.5.4.42 NAME ’givenName’ 
SUP name ) 


Examples: "Andrew", "Charles", and "Joanne". 

2.13. ‘houseIdentifier’ 
The 'houseldentifier” attribute type contains identifiers for a 
building within a location. Each identifier is one value of this 


multi-valued attribute. 
(Source: X.520 [X.520]) 
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( 2.5.4.51 NAME ’houselIdentifier’ 
EQUALITY caseIgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX 1..3.,6.1.4.1.1466115.,121:1.15 >) 


1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax 


[RFC4517]. 
Example: "20" to represent the house number 20. 
2.14. ‘initials’ 


The 'initials” attribute type contains strings of initials of some or 
all of an individual’s names, except the surname(s). 
one value of this multi-valued attribute. 

(Source: X.520 [X.520]) 


Each string is 


( 2.5.4.43 NAME “initials'” 
SUP name ) 


Examples: "K. A." and "K". 
2.15. “internationalISDNNumber” 


The ’internationalISDNNumber’ attribute type contains Integrated 
Services Digital Network (ISDN) addresses, as defined in the 
International Telecommunication Union (ITU) Recommendation E.164 


[E.164]. Each address is one value of this multi-valued attribute. 
(Source: X.520 [X.520]) 


( 2.5.4.25 NAME '“internationalISDNNumber' 
EQUALITY numericStringMatch 
SUBSTR numericStringSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) 


1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax 
[RFC4517]. 


Example: "0198 333 333". 


Zal6. CL? 


The '1' ('localityName” in X.500) attribute type contains names of a 
locality or place, such as a city, county, or other geographic 


region. Each name is one value of this multi-valued attribute. 
(Source: X.520 [X.520]) 
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( 2.5.4.7 NAME /1’ 


SUP name ) 
Examples: "Geneva", "Paris", and "Edinburgh". 
Da LTN ‘member’ 


The ’member’ attribute type contains the distinguished names of 
objects that are on a list or in a group. Each name is one value of 
this multi-valued attribute. 

(Source: X.520 [X.520]) 


( 2.5.4.31 NAME “member” 
SUP distinguishedName ) 


Examples: "cn=James Clarke, ou=Finance, o=Widget\, Inc." and 
"cn=John Xerri, ou=Finance, o=Widget\, Inc." may 
be two members of the financial team (group) at Widget, 
Inc., in which case, both of these distinguished names 
would be present as individual values of the member 
attribute. 


2.18. ‘name’ 


The 'name” attribute type is the attribute supertype from which user 
attribute types with the name syntax inherit. Such attribute types 
are typically used for naming. The attribute type is multi-valued. 


It is unlikely that values of this type itself will occur in an 
entry. LDAP server implementations that do not support attribute 
subtyping need not recognize this attribute in requests. Client 
implementations MUST NOT assume that LDAP servers are capable of 
performing attribute subtyping. 

(Source: X.520 [X.520]) 


( 2.5.4.41 NAME “name” 
EQUALITY caseIgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX 1.3.6:1.4.1.1466.. 115.121.115 4 


1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax 
[RFC4517]. 


221.9%. “0% 
The ’o0’ (‘’organizationName’ in X.500) attribute type contains the 


names of an organization. Each name is one value of this 
multi-valued attribute. 
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(Source: X.520 [X.520]) 


( 2.5.4.10 NAME 'o' 
SUP name ) 


Examples: "Widget", "Widget, Inc.", and "Widget, Incorporated.". 


2.20. “ou” 


The ’ou’ (’organizationalUnitName’ in X.500) attribute type contains 
the names of an organizational unit. Each name is one value of this 
multi-valued attribute. 
(Source: X.520 [X.520]) 


( 2.5.4.11 NAME “ou” 


SUP name ) 
Examples: "Finance", "Human Resources", and "Research and 
Development". 
221.3 ‘owner’ 


The ’owner’ attribute type contains the distinguished names of 
objects that have an ownership responsibility for the object that is 
owned. Each owner’s name is one value of this multi-valued 
attribute. 

(Source: X.520 [X.520]) 


( 2.5.4.32 NAME “owner” 
SUP distinguishedName ) 


Example: The mailing list object, whose DN is "cn=All Employees, 
ou=Mailing List,o=Widget\, Inc.", is owned by the Human 
Resources Director. 


Therefore, the value of the “owner” attribute within the 
mailing list object, would be the DN of the director (role): 
"cn=Human Resources Director, ou=employee, o=Widget\, Inc.". 


2.22. ‘'physicalDeliveryOfficeName’ 


The 'physicalDeliveryOfficeName” attribute type contains names that a 
Postal Service uses to identify a post office. 
(Source: X.520 [X.520]) 
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( 2.5.4.19 NAME ‘’physicalDeliveryOfficeName’ 
EQUALITY caseIgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX: 1..3,6.1:4:1:1466.U815:.12121.15 ") 


1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax 
[RFC4517]. 


Examples: "Bremerhaven, Main" and "Bremerhaven, Bonnstrasse". 
2.23. ‘postalAddress’ 


The ’postalAddress’ attribute type contains addresses used by a 
Postal Service to perform services for the object. Each address is 
one value of this multi-valued attribute. 

(Source: X.520 [X.520]) 


( 2.5.4.16 NAME ’postalAddress’ 
EQUALITY caseIgnoreListMatch 
SUBSTR caselgnoreListSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) 


1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax 
[RFC4517]. 


Example: "15 Main St.SOttawa$Canada". 
2.24. ‘postalCode’ 
The 'postalCode” attribute type contains codes used by a Postal 
Service to identify postal service zones. Each code is one value of 
this multi-valued attribute. 
(Source: X.520 [X.520]) 
( 2.5.4.17 NAME ’postalCode’ 

EQUALITY caseIgnoreMatch 

SUBSTR caselgnoreSubstringsMatch 

SYNTAX: 1:63:60 L 4: L71466:L15. 121.415) 


1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax 
[RFC4517]. 


Example: "22180", to identify Vienna, VA, in the USA. 
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2.25. ‘postOfficeBox’ 


The ’postOfficeBox’ attribute type contains postal box identifiers 
that a Postal Service uses when a customer arranges to receive mail 
at a box on the premises of the Postal Service. Each postal box 
identifier is a single value of this multi-valued attribute. 
(Source: X.520 [X.520]) 


( 2.5.4.18 NAME ’postOfficeBox’ 
EQUALITY caseIgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 


1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax 
[RFC4517]. 


Example: "Box 45". 
2.26. ‘’preferredDeliveryMethod’ 


The 'preferredDeliveryMethod” attribute type contains an indication 
of the preferred method of getting a message to the object. 
(Source: X.520 [X.520]) 


( 2.5.4.28 NAME ’preferredDeliveryMethod’ 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.14 
SINGLE-VALUE ) 


1.3.6.1.4.1.1466.115.121.1.14 refers to the Delivery Method syntax 
[RFC4517]. 


Example: If the mhs-delivery Delivery Method is preferred over 
telephone-delivery, which is preferred over all other 
methods, the value would be: "mhs $ telephone". 


2.27. ‘'registeredAddress’ 


The ’registeredAddress’ attribute type contains postal addresses 
suitable for reception of telegrams or expedited documents, where it 
is necessary to have the recipient accept delivery. Each address is 
one value of this multi-valued attribute. 

(Source: X.520 [X.520]) 


( 2.5.4.26 NAME ’registeredAddress’ 


SUP postalAddress 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) 
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1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax 
[RFC4517]. 


Example: "Receptionist$Widget, Inc.$15 Main St.$OttawaSCanada". 
2.28. ‘roleOccupant’ 


The ’roleOccupant’ attribute type contains the distinguished names of 
objects (normally people) that fulfill the responsibilities of a role 
object. Each distinguished name is one value of this multi-valued 
attribute. 

(Source: X.520 [X.520]) 


( 2.5.4.33 NAME ’roleOccupant’ 
SUP distinguishedName ) 


Example: The role object, "cn=Human Resources 
Director, ou=Position, o=Widget\, Inc.", is fulfilled by two 
people whose object names are "cn=Mary 
Smith, ou=employee, o=Widget\, Inc." and "cn=James 
Brown, ou=employee, o=Widget\, Inc.". The ’roleOccupant’ 
attribute will contain both of these distinguished names, 
since they are the occupants of this role. 


2.29. 'searchGuide' 
The ’searchGuide’ attribute type contains sets of information for use 
by clients in constructing search filters. It is superseded by 
‘enhancedSearchGuide’, described above in Section 2.9. Each set is 
one value of this multi-valued attribute. 


(Source: X.520 [X.520]) 


( 2.5.4.14 NAME ’ searchGuide’ 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 ) 


1.3.6.1.4.1.1466.115.121.1.25 refers to the Guide syntax [RFC4517]. 
Example: "person#snSEQ". 

2.30. ‘seeAlso’ 
The ’seeAlso’ attribute type contains the distinguished names of 
objects that are related to the subject object. Each related object 
name is one value of this multi-valued attribute. 


(Source: X.520 [X.520]) 


( 2.5.4.34 NAME 'seeAlso' 
SUP distinguishedName ) 
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Example: The person object "cn=James Brown, ou=employee, o=Widget\, 
Inc." is related to the role objects "cn=Football Team 
Captain, ou=sponsored activities, o=Widget\, Inc." and 
"cn=Chess Team, ou=sponsored activities, o=Widget\, Inc.". 
Since the role objects are related to the person object, the 
/seeAlso” attribute will contain the distinguished name of 
each role object as separate values. 


2.31. 'serialNumber” 


The ’serialNumber’ attribute type contains the serial numbers of 
devices. Each serial number is one value of this multi-valued 
attribute. 

(Source: X.520 [X.520]) 


( 2.5.4.5 NAME ’serialNumber’ 
EQUALITY caseIgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 ) 


1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax 
[RFC4517]. 


Examples: "WI-3005" and "XF551426". 

263220 sn" 
The ’sn’ (’surname’ in X.500) attribute type contains name strings 
for the family names of a person. Each string is one value of this 
multi-valued attribute. 


(Source: X.520 [X.520]) 


( 2.5.4.4 NAME ’sn’ 
SUP name ) 


Example: "Smith". 

2533.6 “St! 
The ’st’ (’stateOrProvinceName’ in X.500) attribute type contains the 
full names of states or provinces. Each name is one value of this 
multi-valued attribute. 


(Source: X.520 [X.520]) 


( 2.5.4.8 NAME “st” 
SUP name ) 


Example: "California". 
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2.34. ‘street’ 


The ’street’ (’streetAddress’ in X.500) attribute type contains site 
information from a postal address (i.e., the street name, place, 
avenue, and the house number). Each street is one value of this 
multi-valued attribute. 

(Source: X.520 [X.520]) 


( 2.5.4.9 NAME 'street” 
EQUALITY caseIgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX. 1.3:.6:.1:4.1.,1466:.115.121. 1.15.) 


1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax 
[RFC4517]. 


Example: "15 Main St.". 
2.35. 'telephoneNumber” 
The 'telephoneNumber” attribute type contains telephone numbers that 
comply with the ITU Recommendation E.123 [E.123]. Each number is one 
value of this multi-valued attribute. 
(Source: X.520 [X.520]) 
( 2.5.4.20 NAME ‘’telephoneNumber’ 

EQUALITY telephoneNumberMatch 

SUBSTR telephoneNumberSubstringsMatch 

SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) 


1.3.6.1.4.1.1466.115.121.1.50 refers to the Telephone Number syntax 
[RFC4517]. 


Example: "+1 234 567 8901". 

2.36. 'teletexTerminalldentifier” 
The withdrawal of Recommendation F.200 has resulted in the withdrawal 
of this attribute. 


(Source: X.520 [X.520]) 


( 2.5.4.22 NAME 'teletexTerminalldentifier'” 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 ) 


1.3.6.1.4.1.1466.115.121.1.51 refers to the Teletex Terminal 
Identifier syntax [RFC4517]. 
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2.37. 'telexNumber” 


The 'telexNumber” attribute type contains sets of strings that are a 
telex number, country code, and answerback code of a telex terminal. 
Each set is one value of this multi-valued attribute. 

(Source: X.520 [X.520]) 


( 2.5.4.21 NAME '“telexNumber” 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 ) 


1.3.6.1.4.1.1466.115.121.1.52 refers to the Telex Number syntax 
[RFC4517]. 


Example: "12345S023SABCDE". 
2638: trte 


The ’title’ attribute type contains the title of a person in their 
organizational context. Each title is one value of this multi-valued 
attribute. 

(Source: X.520 [X.520]) 


( 2.5.4.12 NAME 'title' 
SUP name ) 
Examples: "Vice President", "Software Engineer", and "CEO". 


2.39. ‘uid’ 


The ’uid’ ('userid” in RFC 1274) attribute type contains computer 
system login names associated with the object. Each name is one 
value of this multi-valued attribute. 

(Source: RFC 2798 [RFC2798] and RFC 1274 [RFC1274]) 


( 0.9.2342.19200300.100.1.1 NAME ‘uid’ 
EQUALITY caselgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 


1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax 
[RFC4517]. 


Examples: "s9709015", "admin", and "Administrator". 
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2.40. ‘uniqueMember’ 


The ’uniqueMember’ attribute type contains the distinguished names of 
an object that is on a list or in a group, where the relative 
distinguished names of the object include a value that distinguishes 
between objects when a distinguished name has been reused. Each 
distinguished name is one value of this multi-valued attribute. 
(Source: X.520 [X.520]) 


( 2.5.4.50 NAME ’uniqueMember’ 
EQUALITY uniqueMemberMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) 


1.3.6.1.4.1.1466.115.121.1.34 refers to the Name and Optional UID 
syntax [RFC4517]. 


Example: If "ou=1st Battalion, o=Defense,c=US" is a battalion that was 
disbanded, establishing a new battalion with the "same" name 
would have a unique identifier value added, resulting in 
"ou=1st Battalion, o=Defense, c=US#’010101’B". 


2.41. ‘userPassword’ 


The ’userPassword’ attribute contains octet strings that are known 
only to the user and the system to which the user has access. Each 
string is one value of this multi-valued attribute. 


The application SHOULD prepare textual strings used as passwords by 
transcoding them to Unicode, applying SASLprep [RFC4013], and 
encoding as UTF-8. The determination of whether a password is 
textual is a local client matter. 

(Source: X.509 [X.509]) 


( 2.5.4.35 NAME ’userPassword’ 
EQUALITY octetStringMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 


1.3.6.1.4.1.1466.115.121.1.40 refers to the Octet String syntax 
[RFC4517]. 


Passwords are stored using an Octet String syntax and are not 
encrypted. Transfer of cleartext passwords is strongly discouraged 
where the underlying transport service cannot guarantee 
confidentiality and may result in disclosure of the password to 
unauthorized parties. 


An example of a need for multiple values in the ’userPassword’ 
attribute is an environment where every month the user is expected to 


Sciberras Standards Track [Page 19] 


RFC 4519 LDAP: Schema for User Applications June 2006 


use a different password generated by some automated system. During 
transitional periods, like the last and first day of the periods, it 
may be necessary to allow two passwords for the two consecutive 
periods to be valid in the system. 


DAD *x121Address' 


The ’x121Address’ attribute type contains data network addresses as 
defined by ITU Recommendation X.121 [X.121]. Each address is one 
value of this multi-valued attribute. 

(Source: X.520 [X.520]) 


( 2.5.4.24 NAME 'x121lAddress' 
EQUALITY numericStringMatch 
SUBSTR numericStringSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) 


1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax 
[RFC4517]. 


Example: "36111222333444555". 
2.43. 'x500Uniqueldentifier”' 


The 'x500Uniqueldentifier” attribute type contains binary strings 
that are used to distinguish between objects when a distinguished 
name has been reused. Each string is one value of this multi-valued 
attribute. 


In X.520 [X.520], this attribute type is called ’/uniquelIdentifier’. 
This is a different attribute type from both the ‘uid’ and 
“uniqueldentifier” LDAP attribute types. The 'uniqueldentifier' 
attribute type is defined in [RFC4524]. 

(Source: X.520 [X.520]) 


( 2.5.4.45 NAME 'x500Uniqueldentifier' 
EQUALITY bitStringMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) 


1.3.6.1.4.1.1466.115.121.1.6 refers to the Bit String syntax 
[RFC4517]. 


3. Object Classes 


LDAP servers SHOULD recognize all the Object Classes listed here as 
values of the ’objectClass’ attribute (see [RFC4512]). 
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3.1. 'applicationProcess” 


The ’applicationProcess’ object class definition is the basis of an 
entry that represents an application executing in a computer system. 


(Source: X.521 [X.521]) 


( 2.5.6.11 NAME 'applicationProcess' 


SUP top 
STRUCTURAL 
MUST cn 
MAY ( seeAlso $ 
ou $ 
1$ 
description ) ) 
3.2. 'country' 


The ’country’ object class definition is the basis of an entry that 


represents a country. 
(Source: X.521 [X.521]) 


( 2.5.6.2 NAME ’country’ 
SUP top 
STRUCTURAL 
MUST c 
MAY ( searchGuide $ 
description ) ) 


3.3. 'dcObject” 


The 'dcObject” object class permits an entry to contains domain 
component information. This object class is defined as auxiliary, 
because it will be used in conjunction with an existing structural 


object class. 
(Source: RFC 2247 [RFC2247]) 


( 1.3.6.1.4.1.1466.344 NAME ’dcObject’ 


SUP top 
AUXILIARY 
MUST dc ) 


3.4. ‘device’ 


The ’device’ object class is the basis of an entry that represents an 
appliance, computer, or network element. 
(Source: X.521 [X.521]) 
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( 2.5.6.14 NAME ’device’ 

SUP top 

STRUCTURAL 

MUST cn 

MAY ( serialNumber $ 
seeAlso $ 
owner $ 
ou $ 
o $ 
1 $ 


description ) ) 
3.5. 'groupOfNames' 


The ’groupOfNames’ object class is the basis of an entry that 
represents a set of named objects including information related to 
the purpose or maintenance of the set. 

(Source: X.521 [X.521]) 


( 2.5.6.9 NAME ’groupOfNames’ 
SUP top 
STRUCTURAL 
MUST ( member $ 
cn ) 
MAY ( businessCategory $ 
seeAlso $ 
owner $ 
ou $ 
o $ 


description ) ) 
3.6. 'groupOfUniqueNames” 
The ’groupOfUniqueNames’ object class is the same as the 
'"groupOfNames” object class except that the object names are not 


repeated or reassigned within a set scope. 
(Source: X.521 [X.521]) 
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( 2.5.6.17 NAME ’ groupOfUniqueNames’ 


SUP top 
STRUCTURAL 
MUST ( uniqueMember $ 
cn ) 
MAY ( businessCategory $ 
seeAlso $ 
owner $ 
ou $ 
o $ 


description ) ) 


3.7. ‘locality’ 


The ’locality’ object class is the basis of an entry that represents 
a place in the physical world. 
(Source: X.521 [X.521]) 


(2 


.5.6.3 NAME ‘locality’ 
SUP top 
STRUCTURAL 
MAY ( street $ 
seeAlso $ 
searchGuide $ 
st $ 
1 $ 


description ) ) 


3.8. ‘organization’ 


The organization’ object class is the basis of an entry that 


repres 


ents a structured group of people. 


(Source: X.521 [X.521]) 


(2 
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.5.6.4 NAME “organization” 

SUP top 

STRUCTURAL 

MUST o 

MAY ( userPassword $ searchGuide $ seeAlso $ 
businessCategory $ x121lAddress $ registeredAddress $ 
destinationIndicator $ preferredDeliveryMethod $ 
telexNumber $ teletexTerminalIdentifier $ 
telephoneNumber $ internationalISDNNumber $ 
facsimileTelephoneNumber $ street $ postOfficeBox $ 
postalCode $ postalAddress $ physicalDeliveryOfficeName $ 
st $ 1 $ description ) ) 
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3.9. 'organizationalPerson' 


The ’organizationalPerson’ object class is the basis of an entry that 
represents a person in relation to an organization. 
(Source: X.521 [X.521]) 


( 2.5.6.7 NAME ’organizationalPerson’ 

SUP person 

STRUCTURAL 

MAY ( title $ x121Address $ registeredAddress $ 
destinationIndicator $ preferredDeliveryMethod $ 
telexNumber $ teletexTerminalldentifier $ 
telephoneNumber $ internationalISDNNumber $ 
facsimileTelephoneNumber $ street $ postOfficeBox $ 
postalCode $ postalAddress $ physicalDeliveryOfficeName $ 
ou $ st $ 1 ) ) 


3.10. ‘’organizationalRole’ 


The ’organizationalRole’ object class is the basis of an entry that 
represents a job, function, or position in an organization. 
(Source: X.521 [X.521]) 


( 2.5.6.8 NAME ’organizationalRole’ 

SUP top 

STRUCTURAL 

MUST cn 

MAY ( x12lAddress $ registeredAddress $ destinationIndicator $ 
preferredDeliveryMethod $ telexNumber $ 
teletexTerminalldentifier $ telephoneNumber $ 
internationalISDNNumber $ facsimileTelephoneNumber $ 
seeAlso $ roleOccupant $ preferredDeliveryMethod $ 
street $ postOfficeBox $ postalCode $ postalAddress $ 
physicalDeliveryOfficeName $ ou $ st $ 1 $ 
description ) ) 


3.11. 'organizationalUnit” 
The 'organizationalUnit” object class is the basis of an entry that 


represents a piece of an organization. 
(Source: X.521 [X.521]) 
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( 2.5.6.5 NAME ’organizationalUnit’ 
SUP top 
STRUCTURAL 
MUST ou 
MAY ( businessCategory $ description $ destinationIndicator $ 
facsimileTelephoneNumber $ internationalISDNNumber $ 1 $ 
physicalDeliveryOfficeName $ postalAddress $ postalCode $ 
postOfficeBox $ preferredDeliveryMethod $ 
registeredAddress $ searchGuide $ seeAlso $ st $ street $ 
telephoneNumber $ teletexTerminalldentifier $ 
telexNumber $ userPassword $ x12lAddress ) ) 
3.12 ‘person’ 
The ’person’ object class is the basis of an entry that represents a 
human being. 
(Source: X.521 [X.521]) 
( 2.5.6.6 NAME ’person’ 
SUP top 
STRUCTURAL 
MUST ( sn $ 
cn ) 
MAY ( userPassword $ 
telephoneNumber $ 
seeAlso $ description ) ) 
3.13. ‘’residentialPerson’ 


The ’residentialPerson’ object class is the basis of an entry that 
includes a person’s residence in the representation of the person. 


(Sourc 


( 2 
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e: X.521 [X.521]) 


.5.6.10 NAME 'residentialPerson' 

SUP person 

STRUCTURAL 

MUST 1 

MAY ( businessCategory $ x121Address $ registeredAddress $ 
destinationIndicator $ preferredDeliveryMethod $ 
telexNumber $ teletexTerminalIdentifier $ 
telephoneNumber $ internationalISDNNumber $ 
facsimileTelephoneNumber $ preferredDeliveryMethod $ 
street $ postOfficeBox $ postalCode $ postalAddress $ 
physicalDeliveryOfficeName $ st $ 1 ) ) 
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3.14. "uidObject” 


The ’uidObject’ object class permits an entry to contains user 
identification information. This object class is defined as 
auxiliary, because it will be used in conjunction with an existing 
structural object class. 

(Source: RFC 2377 [RFC2377]) 


( 1.3.6.1.1.3.1 NAME /’uidObject’ 
SUP top 
AUXILIARY 
MUST uid ) 


4. IANA Considerations 


The Internet Assigned Numbers Authority (IANA) has updated the LDAP 
descriptors registry as indicated in the following template: 


Subject: Request for LDAP Descriptor Registration Update 

Descriptor (short name): see comments 

Object Identifier: see comments 

Person & email address to contact for further information: 
Andrew Sciberras <andrew.sciberras@eb2bcom. com> 

Usage: (A = attribute type, O = Object Class) see comment 

Specification: RFC 4519 

Author/Change Controller: IESG 


Comments 


In the LDAP descriptors registry, the following descriptors (short 
names) have been updated to refer to RFC 4519. Names that need to 
be reserved, rather than assigned to an Object Identifier, will 
contain an Object Identifier value of RESERVED. 


Oo 
bh 
bh 


applicationProcess 
businessCategory 

Cc 

cn 

commonName 

country 
countryName 

dc 

dcObject 
description 
destinationIndicator 
device 


3 


2.19200300.100.1.25 
.4.1.1466.344 


Orrorrorrrro 
NNNFONNNNNNDND 
aaa Www aaa A 
OY Hs Hs 01) DN Hs DAHA SDA 
PNPRFPBOANWWO 


A JU 
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NAME Type OID 
distinguishedName 2.5.4.49 
dnQualifier 2.5.4.46 
domainComponent 0.9.2342.19200300.100.1.25 
enhancedSearchGuide 2.5.4.47 
facsimileTelephoneNumber PESEE EAE 
generationQualifier 2.5.4.44 
givenName 2.5.4.42 
gn RESERVED 
groupOfNames 6.9 
groupOfUniqueNames aL. 
houseldentifier .51 
initials 43 
international ISDNNumber #25 
ne so 
locality ¿3 
localityName wl 
member +31 
name .41 
o 10 
organization 4 


organizationName 
organizationalPerson 
organizationalRole 
organizationalUnit 


organizationalUnitName TT 
ou 11 
owner 332 
person 

physicalDeliveryOfficeName 19 
postalAddress 16 
postalCode 17 
postOfficeBox 18 


preferredDeliveryMethod 


DO» Pp > py»? pypyp>yO»pypSp>ypyp>O» >» p>NOODOOpOppyp»yp<yOp>pp»>ypP>pp<yOOD»>ppypyppyypy 
DQaannnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnannaan4nwounw 


NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNAN 
Lh Xx AHA DADA DR Os as ls as ss OY ss SA OY OO AS O ls ss O ds ds AAO 
md 


registeredAddress 26 
residentialPerson 10 
roleOccupant ME S) 
searchGuide SLA 
seeAlso .34 
serialNumber z9 
sn .4 
st .8 
street +9 
surname 4 
telephoneNumber 20 
teletexTerminalldentifier .22 
telexNumber .21 
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53 


NAME Type OID 

title A 2.94212 

uid A 0.9.2342.19200300.100.1.1 
uidObject O id Ord 
uniqueMember A 29.4550 

userid A 0.9.2342.19200300.100.1.1 
userPassword A 220% 45.35 

x121Address A 2.5.4.24 
x500Uniqueldentifier A Lao O 


Security Considerations 


Attributes of directory entries are used to provide descriptive 
information about the real-world objects they represent, which can be 
people, organizations, or devices. Most countries have privacy laws 
regarding the publication of information about people. 


Transfer of cleartext passwords is strongly discouraged where the 
underlying transport service cannot guarantee confidentiality and 
integrity, since this may result in disclosure of the password to 
unauthorized parties. 


Multiple attribute values for the 'userPassword” attribute need to be 
used with care. Especially reset/deletion of a password by an 
administrator without knowing the old user password gets tricky or 
impossible if multiple values for different applications are present. 


Certainly, applications that intend to replace the ’userPassword’ 
value (s) with new value(s) should use modify/replaceValues (or 
modify/deleteAttributetaddAttribute). In addition, server 
implementations are encouraged to provide administrative controls 
that, if enabled, restrict the ’userPassword’ attribute to one value. 


Note that when used for authentication purposes [RFC4513], the user 
need only prove knowledge of one of the values, not all of the 
values. 
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Appendix A. Changes Made Since RFC 2256 


This appendix lists the changes that have been made from RFC 2256 to 
RFC 4519. 


This appendix is not a normative part of this specification, which 
has been provided for informational purposes only. 


Ts 


2. 


10. 


Sciberras 


Replaced the document title. 
Removed the IESG Note. 
Dependencies on RFC 1274 have been eliminated. 


Added a Security Considerations section and an IANA 
Considerations section. 


Deleted the conformance requirement for subschema object 
classes in favor of a statement in [RFC4517]. 


Added explanation to attribute types and to each object class. 


Removed Section 4, Syntaxes, and Section 6, Matching Rules, 
(moved to [RFC4517]). 


Removed the certificate-related attribute types: 
authorityRevocationlist, cACertificate, 
certificateRevocationList, crossCertificatePair, 
deltaRevocationList, supportedAlgorithms, and userCertificate. 


Removed the certificate-related Object Classes: 
certificationAuthority, certificationAuthority-V2, 
cRLDistributionPoint, strongAuthenticationUser, and 
userSecurityInformation 


LDAP PKI is now discussed in [RFC4523]. 


Removed the dmdName, knowledgeInformation, 
presentationAddress, protocolInformation, and 
supportedApplicationContext attribute types and the dmd, 
applicationEntity, and dSA object classes. 


Deleted the aliasedObjectName and objectClass attribute type 


definitions. Deleted the alias and top object class 
definitions. They are included in [RFC4512]. 
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TI; 


12. 


13% 


14. 


15. 


16. 


17. 


18. 


T9: 


20. 


Zs 


22. 


23. 
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Added the “dc” attribute type from RFC 2247, making the 
distinction between 'stored” and 'query” values when preparing 
IDN strings. 


Numerous editorial changes. 


Removed upper bound after the SYNTAX oid in all attribute 
definitions where it appeared. 


Added text about Unicode, SASLprep [RFC4013], and UTF-8 for 
userPassword. 


Included definitions, comments and references for 'dcObject” 
and ’uidObject’. 


Replaced PKI schema references to use RFC 4523. 


Spelt out and referenced ABNF on first usage. 


Removed Section 2.4 (Source). Replaced the source table with 
explicit references for each definition. 


All references to an attribute type or object class are 
enclosed in single quotes. 


The layout of attribute type definitions has been changed to 
provide consistency throughout the document: 

> Section Heading 

Description of Attribute type 

Multivalued description 

Source Information 

Definition 

Example 

Additional Comments 


VVVVV WV 


Adding this consistent output included the addition of 
examples to some definitions. 


References to alternate names for attributes types are 
provided with a reference to where they were originally 
specified. 


Clarification of the description of 'distinguishedName” and 
“name”, in regards to these attribute types being supertypes. 


Spelt out ISDN on first usage. 
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25. 


26. 


PASE 


28. 
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Inserted a reference to [RFC4517] for the 
‘teletexTerminalIdentifier’ definition’s SYNTAX OID. 


Additional names were added to the IANA Considerations. Names 
include ’commonName’, *dcObject”, ’domainComponent’, 'GN', 
‘localityName’, ‘’organizationName’, 'organizationUnitName', 
‘surname’, ‘uidObject’ and ’userid’. 


Renamed all instances of supercede to supersede. 


Moved [F.1], [F.31] and [RFC4013] from informative to 
normative references. 


Changed the ’c’ definition to be consistent with X.500. 
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